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Overview 


In order to assure absolute data integrit 
through the amateur network, some form o 
transport layer protocol should be employed 
between the entry and exit points of the network. 
In datagram service, this transport comes in two 
basic forms, the Transmission Control Procedure 
(the TCP in TCP/IP) and the User Datagram 
Protocol, or UDP. The UDP is a very small 
transport protocol, and as such does not provide 
absolute data integrity under all conditions. The 
TCP is a much more robust protocol, and as such is 
capable of assuring absolute data integrity 
through the network, with a much higher overhead. 


The Virtual Circuit amateur network concept 
using the CCITT standards (X.25/X.75) has 
generally relied on the use of the delivery 
confirmation, or D-bit procedures to maintain data 
integrity. Not only is this potentially a 
violation of the ISO seven-layer model, but is 
also inadequate. If a virtual circuit connection 
is lost due to an intermediate packet switch 
malfunction, the D-bit procedures alone may not 

rovide an accurate indication of what data was 
ost due to the malfunction. In addition, use of 
the D-bit provides no mechanism of detecting 
errors within the packet switches (such as memory 
errors) that might corrupt otherwise good data 
flowing through the amateur network. 


This paper BOD OSS the use of another CCITT 
X series protocol to correct for these potential 
deficiencies. This is a new recommendation, 
called X.224, and it describes a multi-class 
Transpoirt Layer protocol that can be used on top 
of the X.25/X.75 Level 3 protocols. I will not 
give a detailed protocol specification here, but 
rather describe the different classes of the 
protocol and some of how they function. 


Transport Layer Responsibilities 


The basic function of the Transport Layer is 
to make sure that data traveling from the source 
end-point of a network to the destination end- 
point of the network does so in the proper order 
and without data corruption (if necessary). The 
Transport Layer relies on the Network Layer for 
providing a method of getting the data through the 
network from the source end-pointt to the 
destination end-point. Once the Transport Layer 
entity is sure that the data leaving it matches 
the data entering its peer Transport Layer entity, 
it will pass the data up to the next layer for 
further processing if required. The Transport 
Layer should have at its disposal some method of 
detecting errors, informing its Transport peer of 
these errors if necessary, and possibly correcting 
some forms of errors commonly encountered. 


Errors Encountered By The Transport Layer 


Before the X.224 Transport Layer 
recommendation is discussed, it might be helpful 
to describe some of the errors and situations a 
Transport Layer might have to deal with. Among 
these situations are: 


Data Loss. 

Data Corruption. 

Data Duplication. 

Data Misordering. 

Data Misdelivery. 

Network flow-controlled. 

Upper layer flow-controlled. 

Network Concatenation and Separation. 
Segmenting and Reassembly. 
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J. Splitting and Recombining. 
K. Multiplexing and Demultiplexing. 


Data Loss 


Loss of data can occur for a number of 
reasons in a network. If an intermediate packet 
switch goes down while holding data it 
acknowledged receiving but before sending to the 
next switch is one example. Total network failure 
is example of absolute data loss. These type of 
failures should be detected and corrected. This 
may mean a request for the missing data should be 
sent, or possibly tearing down the malfunctioning 
connection through the network and informing the 
user of the network failure. 


Data Corruption 


Data corruption is when data passes 
through the network from the source end-point to 
the destination end-point, but something hap peas 
to it along the way to create errors in it. ile 
most of the time data passed through the amateur 
network will be passed from point-to-point using a 
reliable Link Layer pele (such as AX.25), if 
an intermediate packet switch has a memor 
malfunction, data passed through that switch wil 
be corrupted. Since the network corrupted the 
data, there should be some method of detecting and 
correcting this situation, if necessary. 


Data Duplication 


It is possible to have the same data 
delivered to the Transport Layer more than once. 
This happens most frequently when retransmissions 
due to Noes of acknowledgements occur. In 
datagram networks can happen a lot when some type 
of flooding mechanism is used to correct network 
deficiencies. There should be some sort of 
detection of duplicated data, which results in the 
duplications being thrown out. 


Data_Misordering 


With some network desi ns, it is 
possible for a group of data send be 4ore another 
group to arrive at_the destination AFTER the 
second send group. This is common with datagram 
networks employing some sort of dynamic network 
routing scheme. ot only should this be detected, 
but some method of data re-ordering must be used 
to regain the original data order. 


Data_Misdelivery 


Whenever the Transport Layer receives 
data from the Network Layer that it does not 
understand what to do with for reasons other than 
specified, it should have some method for acting 
upon the error. This can be as simple as ignoring 
the bad data, or as drastic as tearing down the 
Transport connection and notifying the user that 
the network has failed. This is kind of a catch- 
all for the "I'm so confused" feeling. 


Network Flow-Controlled 


While not an error, if not properly 
handled network flow control could cause the 
Transport Layer to become congested when the upper 
layer(s) keeps sending data that the Transport 
Layer cannot send over the network. Some method 
of flow-controlling the URper layer(s) should be 
employed to prevent data loss due to this 
potential situation. 
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Upper Layer Flow Controlled 


This is also not an error, but rather a 
situation that could cause errors. If the upper 
laver(s) cannot accent more data from the 
network-through the Transport Layer, that upper 
layer(s) may try to stop further data from 
reaching it from the Transport Layer. If the 
Transport Layer is not capable of reacting 
properly, data may become lost between the layers. 


Network Concatenation and Separation 


Some networks allow the Network Layer 
protocol to concatenate more than one Transport 
Layer data unit into a single Network Layer data 
unit at the source end-point, and then separate 
the Transport Layer data units at the destination 
end-point. This may cause some problems at the 
Network/Transport Layer interface, which must be 
handled by the Transport Layer. 


Segmentation and Reassembly 


If the Seer cay Layer receives data 
from the He per layer(s) in a group or size that it 
cannot handle in a single Transport Layer data 
unit, it should break the data into multiple 
smaller Transport data units for sending throu fh 
the network. The destination Transport Layer en 
point should be capable of reassembling these 
samller data units into their original form before 
passing the data to the upper layer protocol(s). 
Some method of indicating this segmenting must be 
employed, along with some numbering scheme to make 
sure the data is reassembled properly at the 
destination end-point. 


Splitting and Recombining 


Occasionally Transport Layer protocols 
may use more than one network connection to 
support the same Transport Layer connection. If 
this happens, some of the above mentioned data 
errors may occur, especially data misorderin 
ede procedures may be required to support this 

unction. 


Multiplexing and Demultiplexing 


This is when a single Network Layer 
connection is shared multiple Transport Layer 
connections. _This will happen frequently, since 
it will result in reduced Network Layer overhead. 
Some method of assuring proper demultiplexing 
should be employed, otherwise the wrong user may 
get someone elses data. 


There are more potential errors that can 
reer into the network system. The above 
highlights(?) some of the more common problem 
areas. 


CCITT X.224 Recommendation 


The CCITT has written Recommendation X.224 to 
serve as_a Transport Layer Specification for Open 
Systems Interconnection networks. It is designed 
to be flexible enough to be used with a variety of 
Network Layers operating underneath it, while 
requiring a minimum amount of overhead. 


Like most Transport Layer protocols, X.224 is 
designed to establish a "virtual connection" 
between two Transport Layer peers. In order not 
to ruffle the feathers of the datagramies, I will 
use the term "logical connection" in place of 
"virtual connection" throughout the rest of this 


paper. 


One of the peers in this logical connection 
is called the source end-point, and the other is 
called the destination end-point. This is not 
meant to imply that data flows only in one 
direction, but rather that when an upper layer 
protocol sends a Transport Layer some data, as far 
as that data is concerned, it is at the source 
end-point of the Transport Layer connection. The 
source Transport Layer end-point then adds any 
overhead to the data that it may require for 
proper Transport Layer operation, and sends the 
resulting data to the Network Layer below it for 
transferring the data across the network to the 
destination Transport end-point. 


The destination Transport Layer end-point 
then receives the data from its Network Layer, 
strips off and acts upon the overhead added by the 
source Transport end-point? and if everything is 
fine, asses the resulting data to its upper 
layer(s) for further processing. 


As long as it is required to transfer data 
between network users, and no major errors occur, 
the logical connection between the two Transport 
Layer peers is maintained. Some errors can be 
recovered from using X.224 procedures, while 
others require tearing down, and re-establishin 
the rogeead connection, if it is still wante 
after the error. 


In order to provide one recommendation that 
is robust enough to handle different qualities of 
service a eae by different networks, X.224 uses 
five different classes of protocols. This has the 
advantage of not requiring unnecessary overhead 
when using network protocols that provide a high 
degree of reliability, while allowing the overhead 

ay to support network protocols that less 
a ity of service. 


CCITT X.224 Classes 
The five classes of X.224 are: 


Class 0. Simple Class. 

Class 1. Basic Error Recovery Class. 

Class 2. Multiplexing Class. 

Class 3. Error Recovery and Multiplexing. 
Class 4. Error Detection and Recovery CTaas 


The class of Transport Layer protocol 
used is inversely Pope oley to the quality of 
service provided by the Network Layer. If the 
network and the Network Layer protocol provides a 
high quality of service, then a simple Transport 
Layer protocol can be used. When the network 
service quality is poorer., a more sophisticated 
Transport Layer protocol might be required. There 
are three classifications of network quality 
defined in X.224: 


Type A. Network operation with acceptable 
Beane error rate (errors not 
eee by disconnect or reset) 

an acceptable rate of signalled 


errors. 

Type B. Network operate with acceptable 
residua error rate, but 
unacceptable rate of signalled 
errors. 


Type C. Network operation with unacceptable 
residual error rate. 


Class 0. 


Class 0 provides the simplest type of 
Transport Layer connection. It is designed to be 
used with type A network connections. It provides 
the functions necessary for logical connection 
establishment, data transfer with segmenting, and 
error reporting. Flow control relies on network 
provided flow control, and disconnection based on 
network service disconnection. 


Class 1. 


Class 1 provides a basic transport 
connection with minimal overhead, and is usuall 
used with type B networks. The main purpose o 
class 1 is to recover from a network disconnect or 
reset. This is the basic class recommended for 
use in the amateur network over AX.25/AX.75 
Network Layer protocols when absolute data 
integrity is not required. 


Class 1 provides transport connections 
with flow control based on network provided flow 
control, error recovery, expedited data transfer, 
disconnéction, along with the ability to provide 
consecutive transport connections on a network 
connection. In addition to providing Class 0 
functions, Class 1 also provides the ability to 
recover from Network failures without affectin 
the network user. This is the main advantage o 
Class 1, and corrects for a potential problem in 
AX.25/AX.75 network designs. 
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Class 2. 


Class 2 is designed to be used with Lyre 
A networks. It provides a way to multip 1sx 
several transport connections onto a single 
network connection. Class 2 also allows the use 
of transport flow controls to help avoid 
congestion at Transport Layer connections end- 
points. No error detection or recovery is 
provided by class 2. 


; If the network connection resets or 
disconnects, the transport connection is 
terminated, and the user is informed. 


Class 3. 


Class 3 provides the characteristics of 
class 2 with explicit flow control, plus the 
ability to recover from network disconnects or or 
resets from class 1. This is usually used with 
type B networks. 


Class 4. 


Class 4 is the most sophisticated 
Transport Layer protocol, and is designed for use 
with type C networks. In addition to providing 
Class 3 services, it also detects and recovers 
from errors which occur as a result of a low grade 
of service from the network. The kinds of errors 
detected include: 


A. Data Loss. 

B. Out-of-Sequence Data Delivery. 
Cc Data Duplication. 

D Data corruption. 


Detection and recovery from errors is 
enhanced by the extended use of data sequence 
numbering, timeout procedures, anda simple 
checksum system. 


The class of protocol used can be negotiated 
at connection request time. If the preferred 
class is not available, an alternate may be 
selected, if appropriate. 


X.224 Headers 


Figure 1 shows the basic structure for the 
Transport Layer headers used in X.224. These 
headers are an integral number of octets long. 


octet 
1 


! LI ! Fixed Part ! Variable Part ! Data Field ! 


Figure 1. X.224 Transport Layer Header 


LI is the Length Indicator field. It 
indicates how long the Transport header is in 
binary (less the LI itself). The maximum value is 
254 octets (1111 1110). 


The fixed part contains frequently occuring 
parameters, including the coding of the Transport 
Protocol Data Unit (TPDU) type. The length of the 
fixed part is determined by the, type of data unit, 
protocol class, and format in use (normal or 
extended). The coding of the TPDU types are shown 
in Figure 2. 


| TPDU Name ee coding ‘ 
ICR! connect request ‘Ixixtxtx!x! 1110xxxx ! 
'cC! connect confirmation Ix!x!x!x!x! 1101 xxxx 


! 

! 
'DR! disconnect request 'x!x!x!x!x! 10000000 ! 
!'DC! disconnect confirm. ! Ixtxtx!x! 11000000 ! 
'DT! data Ix!x!x!x!x! 11110000 ! 
'ED! expedited data ! txtFflx!x! 00010000 
'AK! data acknowledgement ! tctFix!x! 0110zzzz ! 
‘EA! expedited data ack. ! IxtFix!x! 00100000 ! 
'RJ! reject !otx! tx! | Q10lzzzz 
'ER! TPDU error Ix!x!x!x!x! 01110000 ! 
!PT! Transpart. Protocol Tn ! ! 0 ! 


already in use by other prerecols 
! not al lwed in CCITT X.224 


Figure 2. TPDU Coding and Class Usage 


Where: 
xxxx indicates initial credit allocation in 
oi ea 2, 3, and 4. 0000 in classes 0, 
an 


zz2z indicates initial credit allocation in 
classes 2, 3, and 41111 in class 1. 


F Not available when non explicit flow 
control option is selected. 


Cc Not available when receipt confirmation 
option is selected. 


The variable part is used to indicated less 
frequently used parameters, if any are needed. 
The first octet of each arameter holds the 
parameter code, the second octet contains the 
peraenes value length indicator, and the rest 

olds the parameter value itself. An example of 
use of the variable part is the use of checksums 
for the class 4 protocol. 


The data field contains transparent user 
data, if any. Size restrictions depend on each 
TPDU type. 


TPDU Header Structures 


Figure 3 gives an outline of the structures 
of the headers used. It is not meant to be a 
complete description, just a brief indication of 
TPDU header size. 


_ ., As mentioned above, the LI field is used to 
indicate how long (less the LI field itself) the 
Transport Layer header is. 


The second byte contains the TPDU type, and 
optionally a credit field. 


The DST-REF field is used to contain the 
address of the destination Transport end-point, 
and the SRC-REF holds the address of the source 
Transport end-point. 


Connection requests and Connection 
confirmation headers contain a single-octet field 
that hold the preferred class the requesting 
Transport device wants to use, along with two 
option bits (use/non-use of explicit flow control 
and normal/extended formats in classes 2, 3, or 4. 


Additional parameters may be requested in the 
variable part field, and are selected from among 
the following: 


Transport Data unit size. 

Version Number of Transport protocol. 
Security parameters. 

Checksum operation (class 4). 
Alternative protocol class(es). 
Acknowledge time adjustment. 

pee adhe adjustment. 

Residual error rate. 

Priority of data. 

Transit delay. ' 
Reassignment/resynchronizationtime. 
Expidated data, additional options. 
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: If a disconnect TPDU is sent, it should 
include a reason field which indicates why the 
disconnect was requested. 


Data TPDUs contain a field that contains a 
bit (called EOT) which indicates when a TPDU_is 
the end of asequence of TPDUs. This field also 
contains the TPDU-NR, the TPDU send-sequence 
number. The TPDU-NR is set to zero in class 0, 
and may be any value in class 2 without explicit 
flow control. 


Acknowledgement TPDUs contain a field called 
YR-TU-NR. This field contains the sequence number 
of the next expected data TPDU. It is used to 
indicate the last correctly received data TPDU to 
the source Transport end-point. 


The last type of field used is the reject 
cause field in error TPDUs. As implied, it 
informs the source Transport end-point that the 
destination Transport end-point has rejected a 
TPDU, and why. 
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OCTET Connection Request Header 

{1 1! 2 L 3 ! 4 ! 5 1! 6 ! 7 ! 8 P! P+l 
10110! ! 00000000 00000000 ! ! OPTIONS | PART | 

OCTET Connection Confirm Header 

{1 ! 2 ! 3 { 4 ! 5! ! 7 ! 8 ! Ppl p+ 

! 11101! ! ! ! OPTIONS |! PART! 

OCTET Disconnect Request Header 

{13 2 | 3 ! 4 ! 5 i ! 7 ! 8 ! Pp! p+ 


! 


OCTET Extended Format Class 2, 3, and 4 Data Header 
! 2 ! 3 ! 4 ! 5 6 7 81.9 


a 


! 


OCTET Extended Format Class 2, 3, and 4 Expedited Data Header 
!1 ot 2 ! 3°33! 4 ! 5 6 7 = 8!9 P! P+l 


11000 0000 ! ! i i PART 1! 


OCTET Disconnect Confirm Header 
! 3 ! 4 ! 5 ! 


000 ! 1 {PART 
OCTET . 
11s! Class 0 and 1 Date Header ...end ! 
TLIT___vr___ = USER DATA. | 

! !1111 0000 ! and EOT ! ! 
OCTET Herman former claee 2» 3 and Ps Data Header 


tli 2 P! p+ . wend t 
DST-REF T TPDU-NR VARIA. 5 


TL? DT - 7 
1 $1111 0000 | ! and EOT I PART ! ! 


1s! 
14 z = = e 
!1111 0000 ! ! and EOT ! PART ! 
OCTET Normal Format Class 1, 2, 3, and 4 Expedited Data Header ‘ 
bar 2 a ie ane ae 5 i 6 PI P+] end ! 


1” 10001 0000 ! {and KOT! PART i ! 


...end 


10001 0000 } i and EOT i PART! 


OCTET Normal Format Class 1, 2,3, 4 Data Ack Header . 
i 2 P38 20 4 fo 5 !. 6 P! 


! I 0110' I I ! PART ! 


OCTET Extended Format Class 1, 2, 3, 4 Data Ack Header 
!1 is! 2 -! 3 4 ~=.1 6 7 8 ! 9 10 ! 


5 11 pt 


T CDI” IT VARIABLE? 
! ! PART I 


1" r 0110 0000 I 1 
OCTET Normal Format Class 1, 2, 3, 4 Expedited Data Ack Header . 
11 2 13 04 4 OE 5 6 Pi 


! 10010 0000! ! ! PART 1 
OCTET Extended Format Class1, 2, 3, 4 Expedited Data Ack Header 
!1i! 2 ! 1, 5 67 8 ! 9 P! 
TLE ___ BA —__{____DST- REF —_.___ YR=TU=NR_ 1 VARIABLE _T 
! ! 0010 0000 ! ! l PART I 


OCTET Normal Format Class 1 and 3 Reject Header . 
a 2 ! 3 >! ~«4 ! 5 ! 


! 10101" ! I ! 


OCTET lass 5 Ke ject . 
!1i! 2 ExtendédFormat. 5 6 7 Reject Header 10 ! 
TTLET__&S ! DST ! 4REF YR = TU -8NR 1 9 CDT TT 
! ! 0101 0000 ! ! ! ! 
OCTET 
'1i! 2 | 3 ¢ #4 ! Error Header . PI 
+ T ER——T—_DST REF ? REJECT .:VARTABLE + 
! 0111 0000 ! ! CAUSE ! PART ! 


Figure X.@4 Transport Protocol Data Unit (TPDU) Header Formats 
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P! P+l . end! 


: 
! 


Procedures Available By Class 


Figure 4 shows the various procedures of 


X.224, and in which classes they are available. 

! ! Class ! 
Procedure ! Variant eee] 
!Assignment to network cnct! Ixtxlxlxtx! 
| TPDU data transfer f Ix!x!xtxtx! 
! Segmenting, reassembly ! txlx!xlx!x! 
!{Concatenation, separation ! !olxtxtxtx! 
! Connect. establishment ! txlx!xlx!x! 
! Connection refusal ! Ix!x!x!x!x! 


implicit Ix!! ! ! ! 
explicit ! !x!x!x!x! 
Wxt tal tod 


Normal Release 


Error release 


! Assoc. of TPDU with TCs! Ix! xixtxtx! 
! Data TPDU numbering ! normal ! !x!m!m!m! 
! ! extended ! ! folo!o! 
! Expedited data transfer !met normal ! !m!x!x!x! 
! {net explic.! !o! ! ! ! 
! Reassignment after fail. | !olxh txix! 
| Retention until acknow- !Conf.rept.! !o! ! 1 ! 
! ledgement of TPDUs ! AK 1 Im! txtx! 
! Resvnchronization ! tox! Ixts! 

! Multiplexing, de-muxing ! oo! Ixtxtx! 

! Explicit Flow Control { with ! 1 tmixt!x! 
! | without tx!xlo! !! 


use of rrr t txt 


Checksum : ! 
jnon-use of pale tae or 


Frozen references : Ix! Ixtx! 
! Retransmission on timeout Prd ot dx 
! Resequencing ! eae eae ee ea 
! Inactivity Control ! ted ts We bse! 
! Treatment protocol errors! tx!txtxixt!x! 
! Splitting and Recombining! Rtyd tx 


X.224 Procedures 


It is be 
describe the 
various X.224 classes. 
presented to show that there is an alternative 
Transport protocol to TCP that would work very 


gene the scope of this paper to 
ull operation procedures of the 


The above information is 
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effectively on top of an X.251X.75 type Network 
oho k protocol. I will continue to process the 
X.224 document into a .form that will be 
presentable to amateurs, along with making sure 
that it is 100% amateur compatible. 


The basic operational procedures of X.224 is 
designed to allow a logical connection to be 
established between a source Transport end-point 
and a destination Transport end-point using the 
connection request and connect confirm TPDUs, 
which may be passed along as part of the data 
field of an X.25/X.75 Ntework Layer fast-select 
connect request. 


Once a connection has been established, data 
may flow in both directions, with optional flow 
controls, checksums, and sequence numbers. 
Optionally, expedited data can also be sent. Bad 
data can be rejected if necessary, and protocol 
errors can be detected and signalled. 
iar’ be terminated either explicitly, or by 
inference when the network connection servicing 
the Transport Layer is torn down. 


When the connection is no longer needed, it 


Conclusion 


I believe that X.224 is a viable Transport 
reer protocol to use over an X.25/X.75 network. 
X.224 provides the small extra amount of 
protection over the X.25/X.75 network layer to 
insure absolute data integrity when necessary at a 
very low amount of overhead. Since X.224 is 
similar to AX.25 level 2 operation and X.25/X.75 


network operation, an extensive software 
development campaign is not necessary tQ 
implement this protocol. Level and level 


protocol machines could be modified to provide 
much of the basic core of the X.224 protocol. 


Interested users are encouraged to write the 
author for the latest in X.224 development, along 
with AX.25/AX.75 Network Layer development. It is 
also recommended to join AMRAD, as the AMRAD 
Newsletter contains fairly up-to-date information 
On packet radio development. 


